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PATENT 

ATTORNEY DOCKET NO: 05110/019001 

SYNCHRONIZATION OF DATABASES 
Background of the Invention 
5 The invention relates to synchronizing and updating 

records in databases. 

Often, data and information maintained on a number 
of remote database systems must be transferred to and 
consolidated on a central database. Since the data and 
10 information stored in the various databases change, e.g., 

through addition and deletion of data, the central database 
and the remote database systems have to be "synchronized. 11 
Synchronization is defined as a process by which two 
disparate application databases exchange data so that their 
15 contents become substantially identical. 

Typically, during synchronization, changes in the 
remote database and the central database are transferred 
between the remote database and the central database. For 
example, after the central database is updated, the central 
2 0 database sends to the remote database a confirmation of the 
changes made. During the same message exchange, the central 
database may also transmit to the remote database changes in 
the central database that are of interest to the remote 
database . 

2 5 The remote and central devices performing the 

synchronization of the databases are typically "connected." 
Connected devices have a predetermined turnaround latency. 
In other words, once a device sends a request for 
synchronization to another device, the connection will time 

3 0 out if the other device does not acknowledge the 

synchronization request from the first device within the 
predetermined latency time period. Examples for connected 
environments are the Starfish™ multi-point synchronization 
protocols and the active synchronization protocol from 
35 Microsoft® that operates in a Windows CE™ environment. 
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Before the databases can be synchronized, a 
synchronization mode is negotiated. Four different 
synchronization modes are typically available: (1) Fast Sync 
mode (both sides agree to send only additions, 
5 modifications, and deletions that occurred in the respective 
databases since the last synchronization was exchanged) ; 
(2) Semi -fast Sync mode (both sides agree to send to a 
database only additions and modifications, but not 
deletions; the responder is responsible for determining 
10 deletions that occurred since the last synchronization based 
on differences in the list of records) ; (3) Slow Sync mode 
(all records are exchanged; synchronization is performed 
based on unique record IDs and contains a full history file 
of previous synchronizations; a comparison of the full 
15 records themselves is not required; even applications 

capable of supporting Fast Sync may need to perform Slow 
Sync synchronization in certain cases) ; and (4) Full Re-Sync 
mode (all records are compared based on the full record 
contents, rather than on the history file as in "Slow Sync" 

2 0 mode and exchanged, except for records excluded by a filter; 

filters exclude, e.g., records that exceed a certain size). 

Database updates have four important features: 
(1) consistency (a database is transformed or updated from 
one consistent state to another consistent state) ; 
25 (2) isolation (a transaction remains invisible to a user 
until successfully executed) ; (3) durability (the update 
survives even if this system subsequently crashes) , and, 
more importantly, (4) atomicity (all changes are made or no 
changes are made at all) . With atomicity, a successful 

3 0 execution of the last change request ensures that all 

requested changes were executed successfully. 
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Summary of the Invention 
The invention is directed to reducing message 
traffic during synchronization between a first database 
residing on a first computer (e.g., a remote computer or 
5 initiator) and a second database residing on a second 

computer (e.g., a central computer or responder) . Unlike 
conventional synchronization that operates in a connected 
environment, the invention is capable of synchronizing the 
databases essentially independently of any latency in the 

10 communication channel. 

In general, the first computer transmits to the 
second computer a proposed synchronization mode and at least 
one operation operative on a record stored in the second 
database. The second computer returns to the first computer 

15 a confirmation message accepting the proposed 

synchronization mode. The operation is transmitted to the 
second computer before the second computer returns to the 
first computer the confirmation message accepting the 
proposed synchronization mode. 

2 0 Embodiments of the invention may include one or more 

of the following features. The first computer may transmit 
the proposed synchronization mode and the operations as a 
single message. The operations alone or in combination with 
the proposed synchronization mode may be concatenated into a 

25 single message. Each of the operations can be associated 
with one or more records stored in the first and second 
databases. The operations may control, e.g., the addition, 
deletion, archiving and modification of records in the first 
and second databases. Each of the records may have a unique 

30 record identifier. 

The first computer and the second computer may 
communicate via a message layer having a latency; 
synchronization between the first and the second databases 
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occurs independently of the latency of the message layer. 
The second computer may return to the first computer a 
confirmation message confirming a successful execution of 
the synchronization. The confirmation message may be 
5 returned at a later time, e.g., when the second computer 

receives a subsequent synchronization request from the first 
computer. The second computer may only have to confirm a 
successful execution of the last received operation since a 
confirmation of the last received operation is indicative of 

10 the successful execution of all operations received by the 
second computer. The confirmation message may also include 
one or more operations to be executed on the first computer. 

The second computer may propose to the first 
computer a different synchronization mode if the initially 

15 proposed synchronization mode transmitted by the first 
computer is unacceptable to the second computer. 

The first and second computers may each include one 
or more brokers that manage the respective databases. The 
respective brokers of one computer may be capable of 

20 interpreting and executing the proposed synchronization mode 
and the operations received from the respective other 
computer. 

Further features and advantages of the present 
invention will be apparent from the following description of 
25 preferred embodiments and from the claims. 

Brief Description of the Drawing 
FIG. 1 shows synchronization between an initiator 
and a responder; 

FIG. 2 is a flow diagram of synchronization in a 
30 connected environment; 

FIGS. 3 and 4 show details of the flow diagram of 

FIG. 2; 
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FIG. 5 is a flow diagram of synchronization in a 
connectionless environment ; 

FIG. 6 shows message elements and sample data 
exchanged in a notification; and 
5 FIGS. 7A-7D show message elements and sample data 

exchanged during the processes of FIGS. 2 and 5. 

Description of the Preferred Embodiments 
The invention is embodied in a new lightweight 
protocol, referred to as Notification Transport Protocol 

10 (NotifyXP) 10. The NotifyXP protocol requires relatively 
little network traffic and is useful for communicating 
notification messages between an initiator 14 and 
applications running on a responder 16. NotifyXP also 
defines some procedural frameworks that allow the 

15 notification messages 18, 20 to be used for data 

synchronization. NotifyXP is particularly efficient in 
connectionless operation . 

Referring now to FIG. 1, NotifyXP depends on a 
messaging layer transport 12 which is not part of the 

2 0 invention. NotifyXP assumes that the messaging layer 
transport 12 guarantees: 

1. Message segmentation and re-assembly as required 
by any packet size limitations of the underlying media. 
This includes a guarantee that a message 18, 20 is delivered 

25 in its entirety or not at all, also referred to as 
"atomization" . 

2. Message routing to a specified responder on the 
target device or Network Server. 

3. Any necessary authentication, encryption and/or 
30 compression to provide a secure and efficient transfer of 

NotifyXP message contents. NotifyXP does not perform the 
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actual encryption, compression or data integrity check of 
the message contents. 

If the message layer support that is built into the 
initiator 14 cannot support this functionality, the 
5 implementer of the NotifyXP application may have to provide 
an extra layer between the NotifyXP software and the 
internal messaging transport to extend its capabilities. 
Some message transport layers 12 cannot be extended to 
provide the level of support required by NotifyXP. For 

10 example, a one-way wireless -paging network with a small 

packet size may not be able to support the segmentation and 
re-assembly requirement. A initiator 14 and a responder 16 
can be connected to more than one message transport layer 12 
(not shown) to exchange data using NotifyXP. Moreover, a 

15 number of message transport layers can be combined to 
provide the NotifyXP required level of support. 

NotifyXP can primarily be used to communicate 
messages 18, 20 containing operations 22, 24, respectively, 
between the initiator 14 and the responder 16, as 

20 illustrated in FIG. 1. The initiator 14 is responsible for 
packaging and sending the operations 22 on the message 
transport layer 12. The server or responder 16 is 
responsible for receiving the operations 24 from the message 
transport layer 12 and processing them. 

25 Each message is associated with a "broker" 26, 28 

that interprets and manages a certain set of operations 24 
at the initiator 14 and responder site 16, respectively. A 
broker can be responsible for more than one operation. 
Different brokers 2 8 may interpret different operations 

30 differently. For example, the initiator Broker #1 26 
handling an application "Schedule" interprets an "Add" 
operation (e.g., Operation 2 of Message 1) as a command to 
add a "Schedule" item to the "Schedule" database of the 



responder 16. Broker #2 handling an application "Alert" may 
interpret the same Operation 2 as a command to display a 
message to a user or to sound a beep on a speaker to alert 
the user to an upcoming meeting. 
5 The operations 22 illustrated in FIG. 1 can be 

concatenated. Responder addressing is the responsibility of 
the messaging layer 12. Only one responder 16 can be 
defined in a single NotifyXP message 18. Additional details 
of these operations are listed in the Appendix. Operations 

10 within a message are arranged and interpreted in order. The 
responder Brokers 2 8 are responsible for handling NotifyXP 
operations 24 at the responder 16. NotifyXP uses the 
Operation Brokers 26, 28 for both synchronization and for 
processing application data. 

15 The Brokers 26, 28 are also responsible for defining 

the formats of the application data to be processed, if 
these data are to be stored. The databases store the 
application data in the in the form of records. Each record 
must have an identifier that must be unique for that record 

2 0 within the application database and for the lifetime of the 

database. The identifier contains data that is specific to 
the type of data stored within a database. The identifier 
is understood by both the initiator and responder brokers 
that operate on the record. In certain NotifyXP operations, 
25 the record unique identifier (also called a unique ID) is 
represented as a reserved field with an identifier of zero 
(0) . Each record also has one or more fields in which the 
contents of the record are stored. Each database will 
define whatever fields are required to represent the record 

3 0 data. With the exception of the reserved "Unique ID" zero 

field identifier, these definitions are opaque to NotifyXP. 

NotifyXP Notifications occur between two brokers 2 6 
and 28. For the purposes of a single notification, the 
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broker 2 6 is defined to be the initiator and the other 
broker 2 8 is defined to be the responder. The procedure for 
notification is as follows: 

1. The initiator (client) 14 offers data to the 
5 responder (server) 16. 

2. There is an optional responder' s response (if 
required for unique ID assignment or error reporting) . 

Advantageously, the responder' s response does not 
have to happen immediately, i.e., there can be considerable 

10 latency- The responder' s response also does not have to be 
transmitted via the same underlying message layer transport. 
Certain operations, however, require responses. For 
example, an Add operation of a record to a initiator 
requires a response mapping of the temporary record 

15 identifier to the application database unique identifier for 
the record. Even though the Add operation information is 
communicated using a notification procedure, the unique 
identifier is required by the synchronization procedure. As 
long as the identifier is present before the next 

20 synchronization begins, the synchronization procedure can 

use this data. This means the data can be logged/queued and 
prepended to the next synchronization message that is sent. 
A second example is error reporting which can be 
logged/queued or sent immediately depending upon cost of 

2 5 routing and/or severity of the error. 

Since the databases in question may have very 
different capabilities for storage (e.g., a first device 
vs. a server running Groupware applications), the broker for 
either database can specify preferences or limitations on 

3 0 the data stored. Since the cost of routing data to these 

applications can be expensive (particularly wireless network 
access of first devices) , these preferences are preferably 
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enforced at the initiator. These preferences are often 
enforced as filters (i.e., no records above a certain size) . 

NotifyXP Synchronization occurs between two operation 
brokers 2 6 and 28, with a NotifyXP reserved Operation Broker 
5 involved to control the synchronization procedure in some 
cases (see below) . For the purposes of any one 
synchronization operation, e.g., for Notification, one 
broker is defined to be the initiator and the other is 
defined to be the responder. 

10 The different modes for synchronization were described 

above: Fast Sync mode, Semi -fast Sync mode, Slow Sync mode 
and Full Re-Sync mode. NotifyXP supports all these 
synchronization modes. The synchronization mode that two 
applications will use, depends upon the properties of the 

15 applications. Note that application in this context means 

the application and any other broker (s) which have access to 
the application database. 

Synchronization can occur by two different methods, 
Connected Synchronization and Connectionless 

2 0 Synchroni zat ion . 

Connected Synchronization assumes that the messaging 
layer that NotifyXP uses to transfer its data is 
fundamentally connected and that initiators can expect a 
short latency for a response from responders. 

2 5 A connected link allows the protocol to carry more 

traffic than a link that was trying to conserve the number 
of messages sent and received. A connected link is assumed 
to have less turnaround latency, but requires a higher 
bandwidth. 

3 0 Connected Synchronization requires the presence of 

Operation Brokers 32, 34 referred to as "Synchronization 
Manager Operation Broker" on the responder 16 and the 
initiator 14. The Synchronization Manager Operation Broker 



arbitrates responder resources that are responsible for 
handling the synchronization procedure and handles only two 
operations: "Begin Sync" and "End Sync". "Begin Sync" and 
"End Sync" bracket the individual section synchronization 
5 procedures, with the "End Sync" indicating the end of 
anticipated latencies in the connected synchronization 
procedure . 

The Synchronization Manager Operation Broker can also 
arbitrate the synchronization process by returning an 

10 ordered list of sections that the device should use to offer 
its synchronization data in response to a "Begin Sync" 
operation. This is an optimization to allow the device 
section data to arrive at the responder in the order 
expected by the Synchronization Manager. If there is no 

15 list, the sections can be sent in any order. Additional 
details of the Return Status operation are listed in the 
Appendix. 

Referring now to FIG. 2, in the procedure 10 0 for 
Connected Synchronization, the initiator Synchronization 

20 Manager Broker 32 initiates synchronization negotiations 
with the responder Synchronization Manager Broker 34 by 
sending to the responder Synchronization Manager Broker 34 a 
request for synchronization. The responder responds to this 
request, for example, by defining an ordered list of brokers 

25 for the synchronization, step 102. A so identified 

initiator broker 26 in the negotiated ordered list sends a 
request to negotiate a specific synchronization mode, and 
the responder broker 2 8 identified in the negotiated ordered 
list responds to this request, step 103. If the responder 

30 fails to supply a list of brokers in step 102, the initiator 
selects the next broker 26 in step 103. After the 
negotiation of the synchronization mode is successfully 
completed, initiator broker 26 sends changes in the 
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initiator's database consistent with the negotiated 
synchronization mode to the responder broker 28, step 104. 
Responder broker 28 confirms the changes, step 106. 
Responder broker 28 sends changes in the responder' s 
5 database consistent with the negotiated synchronization mode 
to initiator broker 2 6 and the initiator broker 2 6 confirms 
these changes, step 107. If the ordered list of brokers 
negotiated in step 102 contains other brokers, the procedure 
100 returns to step 103. 

10 Otherwise, the procedure 100 terminates when the 

initiator Synchronization Manager Broker 32 sends an End 
Sync command to the responder Synchronization Manager Broker 
34, step 109. 

Details of the negotiation of the synchronization 

15 protocol are illustrated in FIG. 3. The initiator 

Synchronization Manager Broker 32 starts the synchronization 
procedure for one or more operation brokers, step 12 0, by 
sending a "Begin Sync" operation to the Synchronization 
Manager Operation Broker 34, step 122. The "Begin Sync" 

2 0 operation proposes a list of sections to be synchronized. 

The responder checks if an error code was detected, 
step 124, and sends either an error message, step 126, or a 
"Return Status" operation to the initiator, step 128. If no 
error code was detected, the "Return Status" operation 

25 allows the procedure to continue with a list of sections to 
be synchronized. The following steps are implemented for 
each pair of operation brokers that must synchronize their 
data . 

The initiator requests synchronization from the 
30 responder broker by sending a "Begin Section" operation 

which specifies the requested synchronization mode(s) to be 
used, step 130, and explicitly requests a "Return Status" 
operation in response. The responder can accept the 
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requested synchronization mode or specify a mutually 
acceptable mode in the ext ra data associated with the 
"Return Status" operation, step 132. The responder then 
sends the appropriate "Return Status" operation to the 
5 initiator, step 134. 

Referring now to Fig. 4, after receiving the "Return 
Status" operation in step 134 of FIG. 3, the initiator 14 
sends all changes to the responder broker 2 8 of the local 
application database, step 140. Each change represents a 

10 single operation 22, 24 and all operations explicitly 

request a response from the responder broker, as discussed 
below. These operations can be concatenated in single 
message for efficiency. 

The responder 16 then processes each operation, step 

15 146, and after processing, step 148, sends an acknowledgment 
to the initiator 14 that the operation has been successfully 
processed, step 152. The initiator then transmits the next 
operation, step 158, or transmits an "End Section" 
operation. If the operation was not successfully processed, 

2 0 then the responder removes the operation from the reply and 

notifies the initiator that the operation was not processed, 
step 154. Note that transmission of these acknowledgements 
by the responder indicates that the operation was 
successfully processed and not merely received. The 
25 responder can wait until it has received the "End Section" 
operation from the initiator to send the requested "Return 
Status" operations to reduce the number of messages sent. 

Once the initiator has transmitted all of the changes, 
it transmits an "End Section" operation, step 142. This is 

3 0 the way the responder broker is informed that the 

synchronization changes have been completely transmitted. 
The responder then computes the changes on its own local 
database, step 156 and retransmits the operations to the 
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initiator to inform the initiator responder of the changes. 
The responder retransmits the operations following the same 
steps as the initiator. The responder, of course, does not 
have to negotiate the synchronization mode when it offers 
5 its data and can therefore use a form of the "Begin Section" 
operation which does not specify a requested synchronization 
mode . 

Returning now to FIG. 2, the synchronization steps 104 
and 106 are performed for all Operation Brokers required by 

10 the initiator. The initiator then sends an "End Sync" 

operation to the Synchronization Manager Operation Broker to 
indicate that synchronization has been completed. 

Synchronization can be negotiated for the mode to be 
used with each database section/ broker. In addition, each 

15 broker can supply a list of possible modes to use during 
synchronization in order of preference. This allows the 
responder broker to use some intelligence to propose a 
different sync mode if the first preference for a 
synchronization mode is not available on the responder. 

2 0 Further details about the "Begin Section" operation are 

provided in the Appendix. 

The responder controls the details for synchronizing 
the database. An initiator may propose some sections in a 
"Begin Sync" operation that are not supported on the 
25 responder. The responder then removes these operations from 
the list sent as a reply. Conversely, the responder may not 
return any database sections in its reply that are not 
present in the initiator's "Begin Sync" operation. 

The second approach is called Connectionless 

3 0 Synchronization and makes no assumption (or has no knowledge 

about) the turnaround latency of the messaging layer. The 
goal is to minimize the number of messages exchanged. This 
approach can also be used on a "connected" messaging layer. 



Since turnaround latency is not an issue for connectionless 
synchronization, no Synchronization Manager Operation 
Brokers are required. 

Referring now to FIG. 5, in the procedure for 
5 Connectionless Synchronization 110, the initiator transmits 
a single message which contains both the proposed 
synchronization mode and the operation to be performed, step 
112. In step 112, the initiator requests synchronization 
from the responder broker by sending a "Begin Section" 

10 operation which includes all of the following: the requested 
synchronization mode to be used, the operations specifying 
all of the changes appropriate for the requested 
synchronization mode, and an "End Section" operation to 
indicate the end of the offered data. These operations are 

15 sent as a single concatenated message. Note that not every 
individual operation has to be confirmed separately since 
the message layer guarantees that a message will be 
delivered in its entirety or not delivered at all. 

Once the responder has received the "End Section" 

2 0 operation from the initiator and accepts the synchronization 

mode, step 113, the responder begins building its response 
message to the initiator, but transmits the message only 
after the information to be transmitted in the message is 
complete. The first operations contained in the message of 
25 the responder are the "Return Status" operations to the 

initiator's offered operations. The responder then adds a 
"Begin Section" operation to the outgoing message. Since in 
the present example the responder accepted the requested 
synchronization mode, the responder' s "Begin Section" 

3 0 operation does not have to specify a synchronization mode. 

The responder appends all changes to the message that were 
executed by the responder, including a request for a 
response from the initiator for the last operation. 
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Finally, the "End Section" operation is added to the end of 
the message and the message is sent to the initiator, step 
116. Once the initiator has received the "End Section" 
operation from the responder, the initiator may respond by 
5 acknowledging that the responder's offered data have been 
processed. The initiator may send this response either 
immediately after receiving the message from the responder 
or, alternatively, with the next synchronization of the 
database. Sending the confirmation with the next 

10 synchronization request advantageously reduces message 
traffic on the message transport layer. 

If the responder, however, does not accept the 
synchronization mode proposed by the initiator, step 113, 
then the responder must renegotiate the synchronization mode 

15 by specifying the desired synchronization mode, step 114. 

The initiator must prepare supplemental operations to offer 
back to the responder. The operations required to satisfy 
the responder's newly requested synchronization mode can 
omit those operations that were already sent in the initial 

20 initiator operation offer. The initiator brackets all these 
operations with "Begin Section" and "End Section" operations 
and sends the message. 

Under the most favorable conditions, Connectionless 
Synchronization requires only two (2) NotifyXP messages. 

25 This is the case if none of the initiator's operations 

require a response from the responder and if the responder 
does not have to transmit any operations to the initiator, 
except to indicate the end of the synchronization procedure. 
These are short messages. 

3 0 As mentioned above, the initiator does not have to 

acknowledge receipt of the responder's operation until the 
next required contact with the responder, which can be a 
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subsequent synchronization procedure or a notification 
procedure . 

In the worst case, a maximum of four (4) NotifyXP 
messages are required when the responder redefines the 
5 synchronization mode. 

The following discussion will explain the structure of 
the NotifyXP protocol in more detail. Although NotifyXP is 
defined to function as a connectionless protocol, its client 
and server are statef ul . As described above, each NotifyXP 

10 message includes one or more NotifyXP operations. Each 
operation that is sent by the NotifyXP client, changes 
either the state of the NotifyXP server or the state of the 
application data to which the NotifyXP server interfaces. 
NotifyXP operations consist of a byte opcode followed by two 

15 bytes of the length of optional additional data in network 
byte order followed by any optional additional data. These 
aspects of NotifyXP are discussed in greater detail in the 
Appendix. 

As also discussed above, NotifyXP operations may or may 

2 0 not require a response from the operation responder. 

NotifyXP operations that require a response have the most 
significant bit of the opcode byte set. It is possible to 
request that a single operation be performed with or without 
an expected response operation. If an operation fails, a 
25 NotifyXP broker must return a non-successful status for an 
operation regardless of whether a response was explicitly 
requested. NotifyXP servers do not have to return status 
for operations that were performed successfully unless a 
response is explicitly requested. 

3 0 NotifyXP clients can use this feature to ensure 

successful positive acknowledgement of operations while 
minimizing message traffic. For example, a NotifyXP 
initiator sends a series of operations. The initiator needs 
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to know about the success of each and every operation, but 
only the last operation sent in a message requires an 
explicit response, because the messaging layer guarantees 
complete delivery of messages. The responder is also 
5 required by NotifyXP to process operations in order of 

receipt and must return error status even if a status return 
is not explicitly requested. Therefore, the absence of a 
"Return Status" operation with an error before the final 
"Return Status" operation indicates that all operations up 

10 to the final operation were processed successfully. 

Referring now to FIG. 6, a NotifyXP message notifies a 
responder broker of a request to add of a new record and to 
delete an existing record. The "Date Book" broker processes 
these requests. 

15 This message requests a response to the "Add" 

operation. The first line of data specifies an "Add" 
operation, the second line the lengths of the operation 
including the data to be added and the third line a 
temporary record ID. Line four specifies that a total of 

2 0 three fields will be added (Field 1: the name; Field 2: the 

telephone number; and Field 3: the date and time of the 
appointment), lines 5-13. As discussed in the Appendix, the 
server will return a unique ID (line 16) after each 
successful "Add" operation to allow record ID mapping. 
25 Depending upon the device rules for cost of routing, 

available messaging layer transports, etc., the device can 
respond immediately or queue the response until the next 
time the response can be transmitted. The responder may, 
but is not required to, return a "Return Status" operation 

3 0 with a unique ID to indicate success if the device supports 

Unique ID assignment. 

Referring now to FIG. 7A to 7D and also to FIGS. 2 and 
5, Connected Synchronization is compared with Connectionless 



Synchronization for a single section. The initiator 
operations are in boldface and the responder operations are 
in italic. Blank lines are used for readability but do not 
imply message boundaries. For example, the most efficient 
5 message coding of the Connected Synchronization contains 

four (4) initiator messages to the responder (FIGS. 7A with 
2 messages and FIGS. 7B and 7D with 1 message each) and 
three (3) responder messages to the initiator (FIGS. 7A with 
2 messages and FIG. 7C with 1 message) . The Connectionless 

10 Synchronization reduces the minimal number of required 

messages for synchronization to one (1) initiator messages 
to the responder (1 message concatenated from the operations 
of FIGS. 7A and 7B, respectively) and one (1) responder 
message to the initiator (FIG. 7C) . 

15 As seen in FIG. 7A, the synchronization procedure in 

the connected mode begins with a request from the device to 
the Synchronization Manager operation broker to begin 
synchronization. The request specifies two sections: Date 
Book and Address Book. In the selected example, the 

20 responder only supports synchronization to the Date Book. 

Therefore, the request is accepted with the "Return Status" 
operation that indicates that the only section to be 
synchronized is the Date Book. Note that the identifier for 
this section is provided for example only - it is the 

25 responsibility of the Synchronization Manager brokers on the 
initiator and responder to agree on values for the section 
identifiers . 

This section is absent in the connectionless mode. 
In both modes, the procedure continues with a request 
3 0 from the device to synchronize all changes to the records 
for the responder broker since December 30 th , 1997 at 8:30 
am using Fast Sync. 
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In the connected mode, the initiator also explicitly 
advertises Slow Sync as a fallback option. The responder 
broker acknowledges the request with a "Return Status 11 
operation. The response indicates that the Fast Sync mode 
5 requested can be used since no other mode was suggested. 

This section is absent in the connectionless mode. 
Referring now to FIG. 7B, the device then offers in 
both modes the full range of proposed changes to the 
responder broker. The proposed changes in the present 

10 example are identical. In this case, there are two 

appointment additions ("John Smith" and "Mary Jones"), which 
include the respective names, telephone numbers and the date 
and time of the appointment. Also requested is one 
deletion. The device then sends an "End Section" operation 

15 to signal that it has transmitted the last of its data and 
that the responder should process the data it received and 
return its own data back to the device. 

Referring now to FIG. 7C, in the connected mode, the 
responder processes the offered device data and generates 

20 "Return Status" operations. Then the responder performs 
synchronization on the new change data received from the 
device and on its own data that have changed since the last 
synchronization. The responder brackets the results of the 
synchronization with "Begin Section" and "End Section" 

25 operations. In this case, the changes resulting from the 
synchronization consist of one modification (a telephone 
number) and one addition (the entry "Terry Adams") . Note 
that the Modify operation does not send all fields, only 
those fields that have changed. The "End Section" operation 

3 0 contains the new "last sync time" that the device stores and 
uses in its next Fast -Sync procedure. 

In the connectionless mode, only the last successful 
change (0x82; Delete) is transmitted from the responder to 



the initiator, since its successful execution indicates that 
all previous changes have also been successfully executed. 
The responder also transmits, like in the connected mode, 
the changes in its own database since the last 
5 synchroni zat ion . 

Referring now to FIG. 7D, in the connected mode, the 
device then acknowledges receipt of the data from the 
responder, including receipt of the new "last sync time" 
from the responder Operation Broker. Finally, the device 

10 sends the End Section message to the responder to indicate 
that all sections have been synchronized. 

In contrast, in the connectionless mode, the device 
confirms only that the update was successfully completed. 
This confirmation can be postponed until the next 

15 synchronization or notification, as mentioned above. 

In other words, in the connectionless mode, when the 
initiator sends its operations, only the last operation in a 
message requires a response. This reduces the number of 
operations the responder must send to the device to properly 

20 acknowledge the device's operations. Only an error 

encountered by the responder broker on the responder while 
processing the operation would require a response from the 
device . 

The connectionless Synchronization Procedure, unlike 
25 the connected Synchronization Procedure, does not enforce a 
fixed response time for each sent message. The time between 
messages can also vary over a wide range. However, unless 
the device and responder brokers have "agreed" upon a 
delayed delivery of responses to outstanding messages and 
3 0 operations, synchronization times should be kept as short as 
possible . 

It is to be understood that the embodiments and 
variations shown and described above are illustrative of the 



principles of this invention only and that various 
modifications may be implemented by those skilled in the art 
without departing from the scope and spirit of the 
invention. 
5 APPENDIX 
1. NotifyXP operations 

The supported NotifyXP operations are described in the 
table below. 



Operation Name 


Operation ID 


Description 


Response? 


Return Status 


0x00 


Return status for a 
previous operation 


No 


Add 


0x01 


Add/Create a record 


Only for Status 




UXUZ 


Delete a record 


Only for Status 


Delete and 


0x03 


Delete a record after 


Only for Status 


Modify 


0x04 


Modify an existing 
record 


Only for Status 


Unmodified 


0x05 


Declare list of 
Uiiiiiou-X jl icq records 


No 


Begin Section 


0x06 


Tag beginning of sync 
oner aaua scream / 
request sync mode 


Only for Status 


End Section 


0x07 


Tag end of sync data 
stream 


Only for Status 


Cancel Procedure 


0x0 8 


Cancel a currently 
pending procedure 


Only for Status 


Request 
Properties 


0x89 


Request operational 
properties 


Advertise or 
Status 


Advertise 
Properties 


OxOA 


Advertise operational 
properties 


No 


Begin Sync 


OxOB 


Tag beginning of sync 
procedure 


Only for Status 


End Sync 


OxOC 


Tag end of sync 
procedure 


Only for Status 


Reserved 


0x0D-0x2F 


Reserved for future use 


No 


User Defined 


0x3 0- 0x3 F 


Range for user defined 
extensions 


No 


Reserved 


0x4 0- 0x7 F 


Reserved for future use 


No 



- 21 - 



10 



15 



20 



25 



Each operation is encoded as a single byte and may have 
additional data bytes associated with it. The following 
sections provide a description of each operation including 
any additional data that the operation specifies. Each 
section also provides a definition of the operation 
structure using modified Backus -Naur Notation (BNF) . The 
BNF definitions use the following terms that are defined for 
use by any operation. 

id-length id-data 



The unique- id 
id- length 
id-data 

temp-record-id = 
field-count 

op-data-length = 

record-field 
field-id 
field-length 
field-value 

binary 

boolean 

date-time 

text 
rrule 
exdate 
BYTE 



BYTE 

binary 

DWORD 

BYTE (value zero is reserved B see 
below) 

(depends on value of Operation Size 
Property) 

field-id field-length field-value 
BYTE 

(same size as op-data-length) 

binary j boolean | date-time j text 
| rrule | exdate 

BYTE * [BYTE] 
n o " j » 2. " 

ISO 8601 time and date ASCII 
representation 

<ASCII or Unicode characters> 
<vCalendar Recurrence Rule> 
<vCalendar Exception Dates/Times> 
<any 8 -bit value> 
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WORD = <2-byte unsigned number in network 

byte order> 

DWORD = <4-byte unsigned number in network 

byte order> 

5 The sizes of the op-data-length and field-length terms 

are defined by the Operation Size Property. Details are 
provided in section "Advertise Properties" in this Appendix. 
The formats of the rrule and exdate properties are 
consistent with those defined in the vCalendar™ 

10 specification, The Electronic Calendaring and Scheduling 

Exchange Format, Version 1.0. vCalendar™ is a trademark of 
Apple Computer, Inc., AT&T Corp., International Business 
Machines Corp., and Siemens. 

Additional information regarding the format of these 

15 rules can be found in the sections 2.1.11 (Basic Recurrence 
Rule Grammar (e.g., "Wl TU TH")) and 2.3.12 Exception 
Date/Times (e.g., "19960402; 19960403")) of the vCalendar™ 
specifications Version 1.0. 

There is one field- id which is reserved for use by 

20 NotifyXP. This is the "Unique ID" field (field-id == 0) . 
This field can be used to communicate a record's unique 
identifier as one of its fields. This convention is used by 
the "Add" and "Modify" operations. For this reason, the 
zero field- id value is reserved and should not be used for 

25 any other field identifier. 



2 . Return Status 

The "Return Status" operation is used to inform the 

responder about the status of a previous operation. The 

"Return Status" operation is defined below using BNF. 

3 0 rs-operation = rs-command op -data -length 

status-header 

rs-command = BYTE (0x00) 
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status-header = operation- status operation-id 

[operation-data] 

operation-status = BYTE (see below) 

operation- id = BYTE 

5 operation-data = (see below) 

The following table shows the supported values for the 
operation-status term. 



Status 


Value 


Meaning 


Success 


0x00 


OK - Success 


Bad Operation 


0x01 


Operation contains malformed syntax 


Unauthori zed 
Operation 


0x02 


Operation needs authentication 


Conflict 


0x03 


Database may be locked 


Unsupported Operation 


0x04 


Operation Not Supported 


Unknown Target 


0x05 


Operation specified unknown target 


Operation Refused 


0x06 


Operation was refused by user 


Responder Busy 


0x07 


Operation could not be processed, 
responder was busy 



The following table shows the method for interpreting 
the operation-id and corresponding operation-data term. 



Operation- ID 


Operation-data 


Description 


Add 


Temp -record- id 
[Unique-id] 


Temporary and optional Unique 
record ID of Add 


Delete 


Unique -id 


Unique record ID of Delete 


Delete and 
Archive 


Unique -id 


Unique record ID of Delete and 
Archive 


Modify 


Unique -id 


Unique record ID of Modify 


Unmodified 
Records 


None 


None 
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Begin Section 


Sync Mode (BYTE) 


Highest supported level of 
sy nchroni z a t i on 


End Section 


None 


None 


Cancel 
Procedure 


None 


None 


Request 
Properties 


None 


None 


Advertise 
Properties 


None 


None 


Begin Sync 


Section-list 


Ordered List of enabled sections 
to synchronize 


End Sync 


None 


None 



The operation data for an Add operation is the 
temporary record identifier followed by the optional Unique 
ID for the added record. Some brokers do not support the 
assignment of temporary record identifiers to Unique IDs 

15 (e.g., brokers on an responder might not need to return a 
Unique ID for a record which was added for their initiator 
client) . Other brokers may want to indicate that an error 
occurred on the Add operation that resulted in a failure to 
assign a Unique ID. These brokers do not have to include 

2 0 the optional Unique ID when responding to the Add operation. 
Like any optional final term in a NotifyXP operation, the 
Unique ID can be omitted by excluding it from the operation 
data using the correct value for op-data-length. 

The Operation data for the "Begin Sync" opcode can 
25 specify an optional ordered list of enabled sections as its 
operation data. The order in which the section identifiers 
appear in the list is the order in which the responder 
expects to receive the section data. The format of the list 
is described below using BNF. 

30 operation-data = section-list 
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section-list 
num- sections 
section-id 



num- sections * sect ion- id 

BYTE 

WORD 



10 



The section- id term must be defined between the 
Synchronization Manager operation broker on the initiator 
and the Enterprise Server. NotifyXP does not specify an 
identifier for database sections. 

"Begin Section" only returns a different sync mode from 
what was requested if the responder broker is unable to 
process the requested sync mode. See the section "Begin 
Section" for an interpretation of the value of the Sync Mode 
BYTE. 



3 . Add 

The "Add" operation is used to specify that a record to 
15 be added by the responder broker. The "Add" operation is 
defined below using BNF . 



20 



add- operat ion 



add- command 



add-header 



add-command op-data-length add- 
header * [record- field] 



BYTE (0x01) 



temp -record- id field- count 



The temp-record-id is assigned by the NotifyXP client 
for the add request. A NotifyXP client will receive a 
successful "Return Status" operation with a unique ID back 
from the server for every successful "Add" operation to 
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allow it to perform record ID mapping. Not all NotifyXP 
brokers support unique identifier assignment. For example, 
a broker that performed transient alerts on the data would 
not need to assign an ID to the data since it would never be 
5 stored on the device. 

There is one other requirement for the Add operation. 
If the responder broker requires the record's unique ID, 
this can be sent using the reserved "Unique ID" field 
(field-id == 0) . This is commonly the case when a initiator 

10 communicates a record addition to a responder (e.g., during 
synchronization) . Generally, the responder does not send 
unique IDs for the new records it adds to the initiator 
client because of storage constraints and because the 
initiator rarely cares about a unique ID for a record in a 

15 database section other than its own. The decision is left 
up to the implementer. 

4. Delete 

The "Delete" operation is used to specify a record to 
be deleted by the responder broker. The "Delete" operation 
20 is defined below using BNF. 



del -operation 



de 1 - c ommand op-data-length 
unique -id 



del -command 



BYTE (0x02) 



5. 



Delete and Archive 



25 



The "Delete and Archive" operation is used to specify a 
record to be archived and deleted by the responder broker. 



- 27 - 



The "Delete and Archive" operation is defined below using 
BNF. 

da-operation = da-command op-data-length unique- 
id 

5 da -command = BYTE (0x03) 

Before deletion, the record should be archived if the 
application database supports archiving. If the database 
does not support archiving a status for the record must be 
returned indicating what actions were performed on the 
10 database. 



6. Modify 

The "Modify" operation is used to update the contents 
of a specified record with the responder broker. The 
"Modify" operation is defined below using BNF. 

15 mod-operation = mod-command op-data-length field- 

count * [record- field] 

mod- command = BYTE (0x04) 



There is one restriction on records used in the Modify 
operation. The record must contain a value for the reserved 
20 "Unique ID" field (field-id == 0) . This is to allow the 
responder broker to know which record is being modified. 



7. Unmodified Records 

The "Unmodified Records" operation is used to indicate 
that the specified record list has not been modified since 
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the last synchronization in the application database that is 
managed by the responder broker. The "Unmodified Records 11 
operation is defined below using BNF. 



ur-operation 
ur- command 



ur - command op - da t a - 1 engt h 
records *unique-id 

BYTE (0x05) 



num- 



num-records 



DWORD 



The num-records term defines how many unique- id terms 
follow. 



10 



15 



8 



Begin Section 



The operation "Begin Section" is used in both types of 
synchronization procedures to tag the beginning of an 
operation stream that will be part of a synchronization 
procedure and, optionally, to request what synchronization 
mode that procedure will use. The operation "Begin Section" 
is defined below using BNF. 



beg -operation 



beg-command op-data- length [sync- 
header] 



beg -command 



BYTE (0x06) 



20 



num-records 



WORD 



sync -header 



sync -mode -list = 



num- records [ sync -mode -list] 

num-modes * (sync -mode [mode-len 
mode -data] ) 



num-modes 



BYTE 
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sync -mode = BYTE (see below) 

mode -1 en = BYTE 

mode-data = (see below) 

The num-records term is a signed value indicating the 
5 number of records that will be sent as the synchronization 
data for the section. If the number of records is unknown, 
the value OxFFFF (-1) can be sent. 

As mentioned in the Synchronization Procedure section, 
a broker may specify that it can operate in more than one 

10 synchronization mode when negotiating a connected 

synchronization procedure. This is to allow the responder 
broker a greater deal of flexibility in deciding which type 
of synchronization to perform. The number of sync modes the 
initiator can support is contained in the num-modes term. 

15 (Note that in a connectionless procedure, only a single mode 
can be specified since the initiator offers all data before 
the responder can respond with its requested sync mode.) 
The following table shows the supported values for the sync- 
mode term and the method for interpreting the corresponding 

20 optional mode-data term. 



Sync -mode 


Value 


Op t i onal Mode - 
data 


Mode -data meaning 


Fast Sync 


0x00 


Date -time term 


Date and time of the last 
synchronization 


Semi-fast 
Sync 


0x01 


Date -time term 


Date and time of the last 
synchronization 


Slow Sync 


0x02 


None 


None 


Full Re -Sync 


0x03 


None 


None 
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The date-time term is in ISO 8601 format. 

In a connected synchronization procedure, the modes 
appear in the order of preference of the initiator. For 
example, assume an initiator that supported Fast Sync and 
5 used a time stamped change log to track changes to the 

database. The first sync mode in the list might be a Fast 
Sync with the last sync time to the current remote, the 
second would be a Fast sync with the time stamp of the 
oldest change in the change log, and the third mode would be 
10 Slow Sync. It is worthy of note in this case that the 

broker would be capable of handling a Fast Sync request for 
any date between the oldest change in the log and the last 
sync time inclusive although a Fast Sync with the last sync 
time is its first choice. 

15 9. End Section 

The operation "End Section" is used to tag the end of a 
synchronization operation stream for the section. This 
operation indicates that the responder broker must apply all 
received operations for the current synchronization 
20 procedure and transition to the next step in the procedure. 
The operation "End Section" is defined below using BNF. 

es-operation = es-command op-data-length [sync- 
date] 

es- command = BYTE (0x07) 

25 sync-date = date-time 

The date-time term is the new synchronization date and 
time for the section in ISO 8601 format. This is sent only 
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from the initiator to the responder and is usually the time 
on the initiator at which the corresponding "Begin Section" 
operation was sent. The initiator and responder will use 
this time as the "last sync time" for the next "Fast Sync" 
5 they perform on this section. 

10. Cancel Procedure 

The "Cancel Procedure" operation is used to request 
that the current procedure (e.g., synchronization) be 
terminated. The "Cancel Procedure" operation is defined 
10 below using BNF. 



Note that op-data- length for this operation is always 
zero. If this operation succeeds, the current procedure is 
15 considered cancelled and both the transmitting and responder 
brokers are responsible for recovering their state. 

11. Request Properties 

The "Request Properties" operation is used to request 
the operational properties of the responder broker. The 
2 0 "Request Properties" operation is defined below using BNF. 



cp-operation 



cp - command op - dat a - 1 engt h 



cp- command 



BYTE (0x08) 



rp- operation 



rp - command op - da t a - 1 eng t h 



rp- command 



BYTE (0x89) 
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The response to this operation is an "Advertise 
Properties" operation and is always required. Note that op- 
data- length for this operation is always zero. 

12. Advertise Properties 

5 The "Advertise Properties" operation is used to inform 

the responder about the operational properties of a broker. 
The "Advertise Properties" operation is defined below using 
BNF . 

ap- operation = ap- command op -data- length 

10 num-properties * [property] 



ap- command 

num-properties 

property 

15 property-id 



BYTE (OxOA) 
BYTE 

property- id property- length 
property- value 

BYTE (see below) 



property- length = WORD 

property- value = (see below) 

The following table shows the supported values for the 
property-id term and the method for interpreting the 
2 0 corresponding property- value term. This table can be 

extended in the future. If a responder does not understand 
any property- id value, it may be skipped in property 
parsing . 
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Property Name 


Property- 
Id 


Value 


Description 


Sync Mode 


0x0 0 


BYTE 


Highest level of sync 
support 


Supported 
Operations 


0x01 


Array of 
BYTEs 


Enumeration of supported 
operations 


Version 


0x02 


3 BYTEs 


Supported version of 
NotifyXP 


Operation Size 


0x03 


BYTE 


Size of op-data- length 
and field-length 



The Sync Mode property describes the highest level of 
synchronization supported by the broker. The values for the 
BYTE are described in the "End Section" operation section. 

10 The Supported Operations property is an array of the 

operation byte codes the broker supports. The Version 
property is the version of NotifyXP that the broker 
supports. The three bytes are interpreted in the following 
manner: the first byte is the major version, the second byte 

15 is the minor version, and the third byte is the revision. 

The Operation Size property is the size in bytes of the 
op-data- length and field- length terms used by the sender. 
The default value for this property is two (2) which means 
that by default, these two terms are WORDs . This default 

20 value is re-initialized with every new message. A NotifyXP 
initiator that wishes to override this default (e.g., it 
needs to send a record which contains a field which is 
longer than 6553 5 bytes) may do so in the following way. 
The initiator includes an Advertise Properties operation 

2 5 that specifies a new value for the Operation Size property 
in the message prior to any operations that require the 
larger size. The Operation Size value then remains as 
specified until either a subsequent Advertise Properties 
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operation changes it again or it reverts back to default at 
the end of the message. 

NotifyXP does not require that remote clients keep 
track of servers to which they connect. However, if a 
client does keep track of servers, it can cache the non- 
transient capabilities of each responder server. It is only 
necessary to advertise the properties of a NotifyXP client 
when : 

1. Previously advertised properties have changed. 

2. The remote specifically requests properties by issuing 
a "Request Properties" operation, 

13 . Begin Sync 

The "Begin Sync" operation is used to initiate a 
connected synchronization procedure. The "Begin Sync" 
operation is defined below using BNF. 

begsync -operation = begsync- command op-data- 
length section-list 

begsync -command = BYTE (OxOB) 

section-list = num-sections *section-id 

num- sections = BYTE 

section- id = WORD 

The section-id term must be defined between the 
Synchronization Manager operation broker on the initiator 
and the Enterprise Server. NotifyXP does not specify an 
identifier for database sections. 



14 . End Sync 



The "End Sync" operation is used to signal the 
successful termination of a connected synchronization 
procedure. The "End Sync" operation is defined below using 
5 BNF. 

endsync-operation = endsync- command op-data- 
length 



endsync- command = BYTE (OxOC) 



What is claimed is: 
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1 1. A method for synchronizing a first database 

2 residing on a first computer with a second database residing 

3 on a second computer, the method comprising: 

4 the first computer transmitting to the second 

5 computer a proposed synchronization mode and at least one 

6 operation operative on a record stored in the second 

7 database ; and 

8 the second computer returning to the first computer 

9 a confirmation message accepting the proposed 

10 synchronization mode, 

11 wherein the at least one operation is transmitted to 

12 the second computer before the second computer returns to 

13 the first computer the confirmation message accepting the 

14 proposed synchronization mode. 

1 2 . A computer program, residing on a 

2 computer- readable medium, for synchronizing a first database 

3 residing on a first computer with a second database residing 

4 on a second computer, comprising instructions for causing: 

5 the first computer to transmit to the second 

6 computer a proposed synchronization mode and at least one 

7 operation operative on a record stored in the second 

8 database; and 

9 the second computer to return to the first computer 

10 a confirmation message accepting the proposed 

11 synchronization mode, 

12 wherein the at least one operation is transmitted to 

13 the second computer before the second computer returns to 

14 the first computer the confirmation message accepting the 

15 proposed synchronization mode. 



1 3. The subject matter of claim 1 or 2, wherein the 

2 first computer transmits the proposed synchronization mode 

3 and the at least one operation as a single message. 

1 4. The subject matter of claim 1 or 2 , wherein the 



2 first computer and the second computer communicate via a 

3 message layer having a latency and wherein the first and the 

4 second databases are synchronized independently of the 

5 latency of the message layer. 



1 5. The subject matter of claim 3, wherein a 

2 plurality of the operations are concatenated in the single 

3 message, 

1 6. The subject matter of claim 1 or 2 , wherein 

2 each of the operations is associated with at least one 

3 record in at least one of the first and second databases. 

1 7. The subject matter of claim 1 or 2, wherein 

2 each of the records comprises a unique record identifier. 

1 8. The subject matter of claim 1 or 2, wherein the 

2 second computer returns to the first computer a confirmation 

3 message confirming a successful execution of the 

4 synchronization. 

1 9. The subject matter of claim 8, wherein the 

2 second computer returns the confirmation message to the 
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3 first computer not before receiving a subsequent 

4 synchronization request from the first computer. 



1 10. The subject matter of claim 8, wherein the 

2 second computer confirms a successful execution of only the 

3 last received operation and wherein the confirmation of the 

4 last received operation is indicative of the successful 

5 execution of all operations received by the second computer. 

1 11. The subject matter of claim 1 or 2, wherein the 

2 operations comprise at least one of adding, deleting, 

3 archiving and modifying records in at least one of the first 

4 and second databases. 

1 12. The subject matter of claim 1 or 2 , wherein the 

2 confirmation message comprises at least one operation 

3 operative on a record stored in the first database. 

1 13. The subject matter of claim 12, wherein the 

2 operations comprise at least one of adding, deleting, 

3 archiving or modifying records in at least one of the first 

4 and second databases . 

1 14. The subject matter of claim 1 or 2 , wherein the 

2 second computer proposes to the first computer a second 

3 synchronization mode if the first proposed synchronization 

4 mode transmitted by the first computer is unacceptable to 

5 the second computer. 
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1 15. The subject matter of claim 1 or 2 , wherein the 

2 first computer is a mobile computer . 

1 16. The subject matter of claim 1 or 2, wherein the 

2 second computer is a host computer. 

1 17. The subject matter of claim 1 or 2 , wherein the 

2 first computer comprises at least one first broker for 

3 managing the first database. 

1 18. The subject matter of claim 1 or 2 , wherein the 

2 second computer comprises at least one second broker for 

3 managing the second database. 

1 19. The subject matter of claim 18, wherein the 

2 second broker is capable of interpreting and executing the 

3 proposed synchronization mode and the at least one operation 

4 received from the first computer. 
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SYNCHRONIZATION OF DATABASES 

Abstract of the Disclosure 

A method for reducing message traffic during 
synchronization between a database residing on a first 
computer (e.g., a remote computer) and another database 
residing on a second computer (e.g., a central computer) 
disclosed. The first computer transmits to the second 
computer a proposed synchronization mode and at least one 
operation that operates on a record stored in the other 
database. The operation is transmitted to the second 
computer before the second computer returns to the first 
computer a confirmation message accepting the proposed 
synchronization mode. Synchronization is essentially 
independent of latency in the communication channel. 



343317. Bll 
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Initiator 



Synchr Manager 
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